Compared with a wired link, a wireless link in the mobile communication system has lower transmission rate and higher bit error rate due to the limitation of physical condition. In order to effectively utilize the limited wireless channel bandwidth resource, a robust header compression technology (hereafter abbreviated as ROHC) is introduced. The core of the ROHC is to utilize the information redundant between packets of service stream to transparently compress and decompress the information in packet header between directly connected nodes. The ROHC technology is described by RFC3095 document of IETF (Internet Engineering Task Force) and revised by the IETF in February, 2007, and the revised document is RFC4815.
Mode is a very important concept in the ROHC. There are three kinds of operation modes defined in the RFC3095 protocol, and they are a Unidirectional mode (hereafter abbreviated as U mode), Bidirectional Optimistic mode (hereafter abbreviated as O mode), Bidirectional Reliable mode (hereafter abbreviated as R mode) respectively.
There is no feedback channel under the U mode, a data packet is only sent in one direction, i.e., the direction from a compressor to a decompressor, and no feedback packet is sent from the decompressor to the compressor. The state change of compressor mainly relies on periodic update and irregular change of header fields in the packet stream. Compression efficiency of the U mode is lower than the other two modes due to periodic update and lacking of feedback mechanism for error recovery. The compression of the ROHC must start from the U mode. The compressor can start to be transformed into other modes after the compressor receives a feedback package indicating the mode transferring.
Similarity exists between the O mode and the U mode, and their difference is in that the O mode has a feedback channel from the decompressor to the compressor for error recovery and important context update. The periodical update is used under the O mode no longer. The target of the O mode lies in furthest increasing the compression efficiency and less utilizing the feedback channel, and the O mode reduces error packages causing by residing error or context invalidity.
There is a greater difference between the R mode and the above two modes, and the important difference is in greatly utilizing of the feedback channel and preventing contexts of the compressor and decompressor from out of step. The sending of the feedback under the R mode is used for confirming all the context updates, including the update of sequence number field. The target of the R mode is in furthest improving the robustness, preventing or reducing the further expansion of package dropping and error package, and also reducing the probability of context invalidity in greatest degree even if the package dropping or error package occur.
Transformation can occurs between various modes, and the mode transformation is initiated by sending the feedback package carrying a CRC checking field from the decompressor to the compressor. It is described in section 5.6 of RFC3095 that three operation modes can transform with each other, and a schematic diagram of the mode transformation is shown in FIG. 1.
Additionally, in section 5.6 of RFC3095 and section 3.1 of RFC4815, in order to optimize the flow of the mode transformation, the protocol introduces two state variables at the compressor side, and the two state variables are C_MODE (compressor mode variable) and C_TRANS (compressor mode transformation state variable) respectively. The value of the C_MODE is in {U, O, R}, and the parameter meanings is respectively U mode, O mode, and R mode; and the initial value of the C_MODE is U. The value of the C_TRANS is in {P, D}, and the parameter meanings is respectively P (PENDING) and D (DONE); and the initial value of the C_TRANS is D.
Two state variables are also introduced at the decompressor side, and the two state variables are D_MODE (decompressor mode variable) and D_TRANS (decompressor mode transformation state variable) respectively. The value of the D_MODE is in {U, O, R}, and the initial value is U; and the value of the D_TRANS is in {I (Initiated), P, D}, and the initial value is D.
The flow of the mode transformation of ROHC is initiated by sending the feedback package carrying a desired target mode by the decompressor. In the present protocol, in addition to the transformation from the U mode to the O mode is completed by one message, all the other mode transformations are completed by way of three-way handshake. The initial, middle and final states in the three-way handshake are described by the above state variables, and the protocol prescribes that:
C_MODE and D_MODE indicate instant states of compressor and decompressor;
PENDING in C_TRANS indicates receiving a state transformation request of the decompressor;
DONE in C_TRANS indicates that the flow of mode transformation at the compressor side is done;
INITIATED in D_TRANS indicates that the decompressor initiates a mode transformation request at the moment;
PENDING in D_TRANS indicates that the decompressor receives a mode transformation request response sent by the compressor;
DONE in D_TRANS indicates that the flow of mode transformation at the decompressor side is done.
FIG. 2 shows a transformation process from the O mode to the R mode.
In FIG. 2, the decompressor continues to keep in the INITIATED state as long as the decompressor have not received IR, IRDYN or UOR-2 compression package of which the mode transformation parameter is set as R. When the C_TRANS is P, the compressor cannot send the compression package of profile 0 or profile 1, i.e., cannot send the compression package of profile 0 or profile 1 before receiving ACK of UOR-2, IRDYN or IR compression package of which the mode transformation parameter is R. After acknowledging the UOR-2, IRDYN or IR compression package, the decompressor receives the compression package of profile 0 or profile 1, and then can set the D_TRANS as D, and the flow ends.
The transformation flow from the U mode to the R mode is the same as the transformation flow from the O mode to the R mode.
FIG. 3 is a transformation flow from the R mode to the O mode.
The decompressor continues to keep in the INITIATED state as long as the decompressor have not received UOR-2, IRDYN or IR compression package of which the mode transformation parameter is set as 0. When the C_TRANS is P, the compressor cannot send the compression package of profile 0 or profile 1, i.e., cannot send the compression package of profile 0 or profile 1 before receiving ACK of UOR-2, IRDYN or IR compression package of which the mode transformation parameter is O. After acknowledging the UOR-2, IRDYN or IR compression package, the decompressor receives the compression package of profile 0 or profile 1, and then can set the D_TRANS as D, and the flow ends.
FIG. 4 is a transformation flow from R mode, O mode to U mode.
After the decompressor acknowledges the first UOR-2(U), IRDYN(U) or IR(U), i.e., the decompressor acknowledges the response of the mode transformation request, the decompressor must continue to send the feedback of which the mode is U, until receiving the compression package of profile 0 or profile 1.
In order to prevent deadlock caused by dropping the feedback message in the three-way handshake flow of the mode transformation flow, the protocol also prescribes that, when the C_TRANS is P, the mode information is included in a sent compression package to send at least periodically (i.e., IR/IRDYN/UOR-2 compression package); when the D_TRANS is P, the decompressor doesn't need to send the feedback for each received message, but must continually send the feedback carrying the CRC according to a certain period (i.e., the final ACK message in the drawing).
In the package format defined in the RFC3095 protocol, only Profile1 type (RTP package type defined in the RFC3095 protocol) IR/IRDYN compression package can carry the mode parameter, and both Profile2 type (UDP package type defined in the RFC3095 protocol) and Profile3 type (ESP package type defined in the RFC3095 protocol) IR/IRDYN compression packages do not carry mode parameters. Thus, in the first handshake, it may result in that the compressor cannot include the mode parameter in the compression package to send, thereby causing that the deadlock occurs during the mode transformation.